Data communication system and methods

ABSTRACT

A data communication system and methods are disclosed. One of the methods includes receiving portions of information such as game content information. The portions are compared to a maximum transmission unit of a network, and combined if their combination is smaller than the maximum transmission unit. Combining of the information portions allows for efficient communication of the information portions. The information portions may also be divided into segments and combined with other portions for communication.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent Application No. 60/596,258, entitled “METHOD AND SYSTEM OF DATA TRANSMISSION AND RECEPTION USING EFFICIENT BANDWIDTH,” filed on Sep. 12, 2005, which is assigned to the current assignee hereof and are incorporated herein by reference in its entirety.

FIELD OF THE DISCLOSURE

The present disclosure relates generally to network communications, and more specifically to a system and method for managing communicative interactions between network elements.

BACKGROUND

A network may be characterized by several factors like who can use the network, the type of traffic the network carries, the medium carrying the traffic, the typical nature of the network's connections, and the transmission technology the network uses. For example, one network may be public and carry circuit switched voice traffic while another may be private and carry packet switched data traffic. Whatever the make-up, most networks facilitate the communication of information between at least two nodes, and as such act as communication networks.

In recent years, several applications have been developed that rely on timely and effective interactions between two or more elements of a communication network. For example, in the sphere of online gaming, hundreds or thousands of game clients executing on user machines may be interacting with a central server executing on a networked computer. With such an architecture, the networked server computer is frequently tasked with providing content to clients, receiving client requests, processing those requests, responding to those requests, and synchronizing those requests with the requests of other clients. Further, the networked server computer can also be tasked with communicating different types of information to the client computer. Certain information, such as information representing player movement, event feedback or other information is communicated frequently in small portions of information. Other information, such as game patches, game world updates, and the like may be communicated less frequently, but includes larger portions of information. The perceived and/or real ability of the game server to communicate the small portions of information may be adversely affected when the larger portions of information are being communicated.

In the gaming context, if communicative interactions are adversely affected or overly numerous, a game player may experience distracting events such as game freezes, stuttering, warping, etc. As such, a need exists for a data communication system and method that manages communicative interactions between network elements.

BRIEF DESCRIPTION OF THE DRAWINGS

It will be appreciated that for simplicity and clarity of illustration, elements illustrated in the Figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements are exaggerated relative to other elements. Embodiments incorporating teachings of the present disclosure are shown and described with respect to the drawings presented herein, in which:

FIG. 1 is a block diagram of a particular embodiment of a network arrangement incorporating teachings of the present disclosure;

FIG. 2 is a block diagram of an alternative particular embodiment of a network arrangement incorporating teachings of the present disclosure;

FIG. 3 is a flow diagram of a particular embodiment of a technique for mixing data packets;

FIG. 4 a flow diagram of a particular embodiment of a technique for mixing data packets; and

FIG. 5 is a block diagram of a particular embodiment of a computing device that incorporates teachings of the present disclosure.

Embodiments discussed below describe, in part, distributed computing solutions that manage all or part of a communicative interaction between network elements. In this context, a communicative interaction may be one or more of: intending to send information, sending information, requesting information, receiving information, or receiving a request for information. As such, a communicative interaction could be one directional, bi-directional, or multi-directional. In some circumstances, a communicative interaction could be relatively complex and involve two or more network elements. For example, a communicative interaction may be “a conversation” or series of related communications between a client and a server—each network element sending and receiving information to and from the other. Whatever form the communicative interaction takes, it should be noted that the network elements involved need not take any specific form. A network element may be a node, a piece of hardware, software, firmware, middleware, some other component of a computing system, and/or some combination thereof.

Though much of the following discussion focuses on specific problems associated with online gaming, the teachings disclosed herein may have broader applicability. As such, discussions relating to gaming issues like lag, game freezes, stuttering, warping, etc. are not intended to limit the scope of the disclosure. In addition, though the specific embodiment described in connection with FIG. 1 involves a Massively Multiplayer Online Game (MMOG), other interactive applications such as Video On Demand, entertainment distribution, information distribution, etc., may also be implemented in a manner that incorporates the teachings disclosed herein.

From a high level, a system incorporating teachings of the present disclosure may include a processor module that monitors communications between a client program resident on a user machine and a server program resident on a computing device remote from the user. The server program may be part of a two-tier architecture that is deployed in a hub and spoke or centralized server configuration. The server program may also be utilized in a less centralized model. For example, the server program may be implemented as one of two or more client programs that perform server-like functionality.

However, the server program is implemented, the processor module may be utilized to effectively reduce the number of communications actually transmitted between the client program and the server program. For example, the processor module may intercept certain client initiated communications intended for the server program, process those communications without server program involvement, and respond to the client program. In some circumstances, the processor module may make it unnecessary to actually send the original client request to the server. Depending upon implementation detail, a different message—one indicating that the original client request has already been handled—may be sent from the processor module to the server. In practice, processing the communications without burdening the server program and without traversing a portion of the network may help reduce problems such as latency, lag, and loss of data coherency. Though the above discussion involves a client-to-server communication, the processor module may also be configured to affect server-to-client communications as well.

As indicated above, this application claims priority to U.S. Provisional Patent No. 60/596,258, filed on Sep. 12, 2005. The provisional applications describe in part specific implementations of the teachings disclosed herein and are not intended to limit the scope of the claims attached below. The entirety of the provisional application is incorporated herein by reference.

Referring to FIG. 1, a block diagram of a particular embodiment of a network arrangement 100 is illustrated. The network arrangement 100 includes a host transmitter device 102 connected to an offload transmitter device 104. The offload transmitter device 104 is connected to a network 108, which is further connected to a receiving node 110. The offload transmitter device 104 includes a mixing function 106, while the receiving node 110 includes an unmixing function 112.

The actual location of mixing function 106 may be modified in other deployments. For example, the mixing function 106 may be located at the host transmitter device 102. Further, the mixing function 106 may be implemented as a processor dongle, a “Lan on Motherboard” processor, etc. The unmixing function 112 may also be implemented at the receiving node 110 or in a different location, and may also be implemented as processor dongle, a “Lan on Motherboard” processor, and the like.

Within arrangement 100, the host transmitter device 102 and the receiving node 110 may be similar or different. For example, receiving node 110 may be a local user computer, a laptop, a cellular telephone, a gaming console, a workstation, or some other appropriate device, and host transmitter device 102 may be a server computer, a workstation, a peer of receiving node 110, or some other appropriate device.

In the embodiment of FIG. 1, network 108 may be a wide area network, such as the Internet, a local area network, or some other appropriate network or bus. Units of information, such as information packets and the like, are communicated via the network 108. The network 108 is characterized by a maximum transmission unit (MTU) which describes the largest amount of information that can be communicated in one unit by the network 108. The MTU can be expressed as a packet size or other appropriate unit.

During operation, the host transmitter device 102 communicates with the receiving node 110 by sending information via the network 108. The information can be divided into portions, and each information portion may be of different sizes. Further, the information portions provided can be smaller than the MTU for the network 108. The information portions are received at the offload transmitter device 104, which analyzes the information portions. If an information portion is smaller than the MTU, or other threshold, the offload transmitter device can apply the mixing function 106 to mix portions of received information together. For example, the host transmitter device 102 may provide different portions of information from different applications operating at the host transmitter device 102. The offload transmitter device 104 can determine that one or more of the provided portions are smaller than the MTU, and can combine the provided portions into an information unit, such as a transmission packet. The transmission packet is communicated to the receiving node 110 via the network 108.

The receiving node 110 receives the transmission packet and analyzes it to determine if the packet includes one or more portions of information. If so, the receiving node 110 applies the unmixing function 112 to the transmission packet to separate each portion of information provided by the transmission packet.

By combining information portions into transmission packets, information may be sent efficiently via the network 108. Further, by placing the mixing function 106 in the offload transmitter device 104, the processing load and overhead for the host transmitter device can be reduced.

Referring to FIG. 2, a particular embodiment of a network arrangement 200, corresponding to the network arrangement 100 of FIG. 1, is illustrated. The network arrangement 200 includes a game server 202 connected to an offload transmitter device 204. The offload transmitter device 204 is connected to a network 208, which is further connected to a game client 210. The offload transmitter device 204 includes a mixing function 206, while the game client 210 includes an unmixing function 212. The game server includes a game application 220 and a game networking module 222. The game application 220 generates portions of information, such as player moves 224 and game patch 226.

In operation, the game server 202 and the game client 210 may communicate with each other via the network 208. In one embodiment game server 202 and the game client 210 may work together to provide a user of game client 210 with an online gaming experience. Game client 210 may receive content generated by the game application 220 from game server 202 and may occasionally send requests game server 202 in an effort to affect the content being provided. As shown, FIG. 2 includes only one device executing a client program. In practice, however, the game server 202 and game application 220 may be providing content to many clients at or near the same time.

For example, in some embodiments, game server 202 may be hosting and serving a massively multiplayer online game (MMOG) environment to hundreds or thousands of users. The content that makes up the environment may include, for example, game objects, game players, images, sounds, text, etc. This content may eventually be received and presented to the user of game client 210 via a computer screen, audio speakers, or other appropriate device.

In the particular embodiment of FIG. 2, game client 210 may implement a local game program or client application that performs several tasks including the receipt of content provided by the game server 202. The game client 210 may process certain content and facilitate a user's interaction with the game application 220. For example, a user may input a game interaction request via some user input device associated with game client 210. The input may “tell” the game client 210 to select game objects, move game objects, interact with other game players, and the like. The game application 210 may receive the game input request.

In some situations, game application 220 may “allow” the request and provide new or altered content based on the allowance. For example, if the game interaction request is to move a game player, the game application 220 can produce the player moves 221 information portion 224 that shows that a player has been moved. In a MMOG environment, the game application 220 may also be tasked with providing the new or altered content to multiple users at multiple locations via network 104. Information portions such as player moves 224 can be relatively small portions of information that are communicated frequently during game activity, in order to provide the user at the game client 210 with the desired game experience.

The game application 220 may also generate relatively large portions of information, such as a game patch information portion 226. The game patch 226 can be generated to adjust the client program at the game client 210, including implementing updated or new game features and content, security features, stability controls, and the like. Other large portions of information can be generated. For example, the game application 220 can generate a pre-cache of game data for the game client 210. This pre-cache can represent game states or other information used to generate subsequent game states at the game client 210. Such pre-caching can reduce lag or other game experience issues at the game client 210.

The large portions of information, such as the game patch 226, can be communicated to the game client 210 via the network 208. However, communication of such large information portions during game activity can interfere with communication of smaller portions of information such as player moves 224. This can result in distracting events (sometimes called lag) such as game freezes, stuttering, warping, and rubber banding. Although transmission of large information portions can be postponed until times of lesser game activity, such as on game startup, this can undesirably delay the implementation or use of the information in the large information portions. For example, a large information portion can include a large update to the gaming environment for multiple clients. It may be desirable to implement this update during periods of active game activity.

The mixing function 206 at the offload transmitter device can mix large information portions with small information portions and transmit the combined portions in a transmission packet to the game client 210. The combined portions are unmixed at the game client 210 for processing. By combining the information portions, the offload transmitter device 204 can maintain the appropriate game experience and provide large portions of information to the game client 210. For example, the offload transmitter device 204 can combine the player moves information portion 224 with the game patch information 226 and provide the combined information to the game client 210. After the information portions are unmixed, the game client 210 can implement the player moves 224 so that the user enjoys the desirable game experience, and also implement the game patch 226 so that the game client 210 includes the latest version of the game client program.

The mixing function 206 can also break down large portions of information into segments, and combine each segment with smaller portions of information for transmission. This can be useful when the large portions of information exceed the MTU of the network 208 or other bandwidth parameter. For example, the mixing function 206 can determine that the game patch 226 exceeds the MTU for the network 208, and therefore divide the game patch into segments. One or more of the segments can be mixed with the player moves 224 into a transmission packet. The transmission packet is received at the game client 210, and the unmixing function 212 unmixes the player moves 224 with the attached segments. The player moves 224 are implemented by the game client 210, while the data segments are stored. The remaining data segments are sent by the offload transmitter device 204, and the unmixing function 212 reconstructs the game patch 226 from the received and stored data segments. Accordingly, the offload transmitter device 204 is able to transmit large portions of information during periods of active game play activity.

Referring to FIG. 3, a flow diagram of a particular embodiment of a method of communicating data is illustrated. At decision block 302 a communication module determines if a packet has been received. If a packet has been received, the method flow moves to block 304, and the communication module determines if the received packet can be added to the current transmission packet without exceeding the MTU for an associated network. Other parameters may also be considered, such as the size of any headers or other information that is appended to the transmission packet.

If the combination will not exceed the MTU, the method flow moves to block 306 and the received packet is added to the transmission packet. The method flow then proceeds to decision block 308, and the communication module determines if the transmission packet is now sized at the MTU. If so, the method flow moves to block 312 and the transmission packet is provided to a transmission stack for transmission. The transmission stack can be a standard transmission stack, so that no additional processing is required to communicate a transmission packet that includes multiple received packets. If, at block 308, it is determined that the transmission packet can accommodate additional data, the method flow returns to decision block 302 to await additional packets.

Returning to decision block 304, if it is determined that the combination of the current transmission packet and the received packet will exceed the network MTU, the method flow moves to block 314 and the communication module subdivides the received packets into segments. Proceeding to block 316, one or more of the segments are added to the transmission packet. In a particular embodiment, segments are added until adding another packet would cause the transmission packet to exceed the MTU. The method flow moves to block 318 and the segments that have not been added to the transmission packet are stored. The stored segments can be added to subsequent transmission packets for transmission. The method flow then moves to block 308.

Returning to decision block 302, if a packet is not received, the method flow moves to decision block 310 and the communication module determines if a time out threshold has been reached. If not, the method flow returns to block 302. If the time out threshold has been reached or exceeded, the method flow moves to block 312 and the current transmission packet is provided to the transmission stack. The time out process allows for partially “full” transmission packets to be sent after a certain period of time. This can be useful in applications such as the game application described above, where it is desirable to communicate game interactions and event updates in a timely manner to provide the desired game experience.

Referring to FIG. 4, a flow diagram of a particular embodiment of a method of unmixing received information portions is illustrated. At block 402, a transmission packet is received at a receiving node. Moving to block 404, the receiving node reads a header of the transmission packet. The header indicates what information is contained in the transmission packet. For example, the header can indicate that the transmission packet includes multiple portions of information, such as player move information and game patch information. The header can also indicate that the transmission packet includes segments of a particular information portion.

Moving to block 406, the receiving node copies any complete information portions in the transmission packet into receive packets. The receive packets can be configured for a receive stack at the receiving node. The receive stack can be a standard receive stack that includes both packets representing data unmixed at the receiving node and packets received directly from a network.

Proceeding to decision block 408, the receiving node determines if there are any data segments in the received transmission packet. If not, the method flow moves to block 416 and the prepared receive packets are provided to the receive stack. If data segments are identified in the transmission packet, the method flow proceeds to block 410 and the identified data segments are added to any stored data segments associated with the same information portion. The method flow then moves to decision block 412 and the receiving node determines if the stored data segments constitute a complete data portion. If not, the method flow moves to block 416 and the prepared receive packets are provided to the receive stack. If a complete information portion is stored, the method flow moves to block 414 and the complete data portion is copied to a receive packet. The method flow then proceeds to block 416.

Referring to FIG. 5, a particular embodiment of a server 500, such as the game server 202 of FIG. 2, is illustrated. The server 500 includes a housing 502 that defines a physical enclosure. Disposed within the housing 502 are a processor 503, a mixing module 504, a network interface 506, and a memory 508. The memory stores a server program 510. The memory 508 is accessible to the processor 503. The mixing module 504 is connected to the processor 503 and to the network interface 506. In some embodiments, the network interface 506 might be built into the mixing module 504, and mixing module 504 may look as though it is a Network Card to the Processor and run via a PCI Bus. In other embodiments, the mixing module 504 may be software or firmware running on the main or other processor.

The processor 503 can be a microprocessor, a microcomputer, a central processing unit (CPU) or other processing device. The network interface 506 can be an Ethernet card or chip or other network interface device. The memory 508 can be a random access memory (RAM), a hard drive, or other appropriate memory device.

During operation, the processor 503 runs the server program 510. The server program 510 can be a game program, a multimedia player such as a video or audio player, or other program. The server program 510 interacts with a client program over a wide area network, as explained with respect to FIG. 1.

For example, the server program 510 can be a game program. During execution of the server program 510, the processor 503 can send game content to a game program resident on a remote client. The game content can consist of information portions, such as player move portions, game patch portions, game update portions, and the like. The mixing module 504 can monitor the portions and determine if the portions can be combined and still remain within the MTU parameters of the network. The mixing module can also break down large information portions into segments and combine the segments with other information portions for transmission.

In addition, the mixing module 504 may be implemented externally to the housing 502. For example, the mixing module 504 can be implemented as a separated device having its own processor and memory. Further, the mixing module 504 can store a persistent copy of the large portions of information received from the processor 503. These stored copies can be used to provide information to clients without further involvement of the processor 503. For example, the mixing module 504 can store a copy of game patch information provided by the processor 503. When a particular client accesses the server 500, such as by initiating a game session, the mixing module 504 can combine the game patch information with other game information and provide the combined information to the client. This relieves the processor 503 from having to monitor which clients have received the patch information, as each client will be provided the patch information when a game session is initiated.

Although only a few exemplary embodiments have been described in detail above, those skilled in the art will readily appreciate that many modifications are possible in the exemplary embodiments without materially departing from the novel teachings and advantages of the embodiments of the present disclosure. Accordingly, all such modifications are intended to be included within the scope of the embodiments of the present disclosure as defined in the following claims. In the claims, means-plus-function clauses are intended to cover the structures described herein as performing the recited function and not only structural equivalents, but also equivalent structures. 

1. A method, comprising: receiving at a communication device a first portion of game information from a first game server external to the communication device; receiving a second portion of game information at the communication device; determining if a combination of the first portion of game information and the second portion of game information exceeds a maximum transmission unit associated with a network; in response to determining that the combination of the first portion of game information and the second portion of game information do not exceed the maximum transmission unit, combining the first portion and the second portion of game information to form a first transmission packet; and sending the first transmission packet to a first game client via the network.
 2. The method of claim 1, wherein the communication device is a software device.
 3. The method of claim 1, wherein the first portion of game information represents player movement information.
 4. The method of claim 1, wherein the second portion of game information represents game patch information.
 5. The method of claim 1, wherein the second portion of game information represents an update of game information for a plurality of game clients.
 6. The method of claim 1, wherein the second portion of game information represents a pre-caching of game content.
 7. The method of claim 1, further comprising: in response to determining that the combination of the first portion of game information and the second portion of game information exceeds the maximum transmission unit: combining a first segment of the second portion of game information with the first portion of game information to form a second transmission packet; sending the second transmission packet to the game client via the network; forming an Nth transmission packet including a second segment of the second portion of game information; and sending the Nth transmission packet to the game client via the network.
 8. The method of claim 7, wherein the Nth transmission packet includes an Nth portion of game information.
 9. The method of claim 1, wherein the second portion of game information is received from a second game server.
 10. The method of claim 1, further comprising: creating a header for the first transmission packet, wherein the header indicates a size of the first portion of game information and a size of the second portion of game information.
 11. The method of claim 1 wherein the first portion of game information is received from a first game application at the game server and the second portion of game information is received from a second game application at the game server.
 12. The method of claim 1, further comprising: storing the second portion of game information at the communication device; receiving an Nth portion of game information at the communication device; combining the Nth portion of game information and the stored second portion of game information to form a second transmission packet; and providing the second transmission packet to a second game client via the network.
 13. A method comprising: receiving a first transmission packet at a game client; determining that the first transmission packet includes a first portion of game information and a first segment of a second portion of game information; storing the first segment of the second portion of game information; receiving a second transmission packet at the game client; determining that the second transmission packet includes an Nth portion of game information and a second segment of the second portion of game information; and combining the first segment and the second segment of the second portion of game information.
 14. The method of claim 13, further comprising: determining that the first transmission packet includes a first segment of an Nth portion of game information; storing the first segment of the Nth portion of game information; receiving a second transmission packet at the game client; determining that the second transmission packet includes a second segment of the Nth portion of game information; and combining the first segment and the second segment of the Nth portion of game information.
 15. The method of claim 13, further comprising: determining a length of the first segment of the second portion of game information based on a header of the first transmission packet.
 16. The method of claim 13, further comprising: storing the first portion of game information in a first receive packet; wherein combining the first segment and the second segment of the second portion of game information comprises storing the first segment and the second segment in a second receive packet; providing the first receive packet and the second receive packet to a receive packet stack of the game client.
 17. A system, comprising: a housing component at least partially defining an enclosure; a first processor located within the enclosure, the first processor operable to execute at least a portion of a locally stored game server and to communicate with a remote game client; and a packet mixing module, the packet mixing module responsive to the first processor and operable to intercept packets of game information between the first processor and the remote game client, to combine the packets of game information to form packets of combined game information, and to transmit the packets of combined game information to the remote game client.
 18. The system of claim 17, wherein the packet mixing module is external to the enclosure.
 19. The system of claim 17 wherein the packet mixing module is a software or firmware module of the first processor.
 20. The system of claim 17, wherein the packet mixing module is further operable to subdivide one or more packets of game information to form subdivided packets of game information, and wherein the one or more of the packets of combined game information includes one or more subdivided packets of game information.
 21. The system of claim 17, wherein at least one of the packets of combined game information includes game patch information and game status information. 